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REMARKS 

This is intended as a full and complete response to the Office Action dated May 
23, 2003, having a shortened statutory period for response set to expire on August 23, 
2003. Please reconsider the drawings, specification, and claims pending in the 
application for reasons discussed below. 

With regard to the drawings, the Examiner objects to Figures 6A, 6B, 8B, 12, 14, 
15, 16B, and 17 for failing to comply with 37 CFR §1.84(p)(5) because they include 
reference sign(s) not mentioned in the description. Applicant respectfully suggests that 
these "reference sign(s)" were omitted as a result of typographical or clerical errors and 
it is obvious from the context of the descriptions in the specification where the 
"reference sign(s)" should have been included. The proposed amendments to the 
specification correct these typographical and/or clerical errors. However, Applicants 
respectfully point out that the objection to tag "1510" is in error. Tag "1510" is 
referenced multiple times in the specification, see page 18 in lines 11-18. Also, two 
sentences were added to the end of the paragraph on page 20 between lines 27 and 28 
to add the tags 1636 and 1638. The support for the first added sentence ("The error is 
handled 1636 if the mismatch exists.") is found, for example, in Figure 16B showing an 
indication of a "YES" along with the arrow interconnecting "MISMATCH?" (element 
1634) and "HANDLE ERROR" (element 1636). The support for the second added 
sentence ("Otherwise, the process is done 1638.") is found, for example, in Figure 16B 
showing an arrow interconnecting "MISMATCH?" (element 1634) and "DONE" (element 
1638). Accordingly, no new matter is added by these amendments. Therefore, 
Applicants respectfully request that the amendments be entered and these objections 
be withdrawn. 

The Examiner objects to Figures 6A, 6B, 8B, 12, 14, 15, 16B, and 17 for failing to 
comply with 37 CFR §1.84(p)(5) because they do not include reference sign(s): "tag 
1511" (pg. 18, line 18); and "method 1600" (pg. 19, line 17). Applicants respectfully 
suggest that these "reference sign(s)" were omitted from the drawings as a result of 
typographical or clerical errors and it is obvious from the context of the descriptions in 
the specification where the "reference sign(s)" should have been included. The 
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proposed amendments to the drawings, Figures 15 and 16, correct these typographical 
and/or clerical errors. No new matter was added to these drawings. Therefore, 
Applicants respectfully request that the proposed drawing corrections be entered and 
these objections be withdrawn. 

Further, the Examiner objects to Figure 15 for failing to comply with 37 CFR 
§1.84(p)(4) because "1542" has been used to designate both "identification tag" and 
"various flags" of pg. 19, line 13. Applicants respectfully suggest that as a result of a 
typographical or clerical error, "1542" was identified for "identification tag" and it is 
obvious from the context of the descriptions in the specification and Figure 15 that 
"1541" should have been identified for "identification tag". The proposed amendment to 
the specification of pg. 19 at line 13 corrects this error and no new matter was added. 
Therefore, Applicants respectfully request that the corresponding proposed amendment 
to pg. 19 at line 13 be entered and this objection be withdrawn. 

With regard to the specification, the Examiner objects to the use of the trademark 
"Java" for failing to be capitalized and accompanied with generic terminology. The 
Examiner also notes that although the use of trademarks is permissible in patent 
applications, the proprietary nature of the marks should be respected and every effort 
made to prevent their use in any manner that might adversely affect their validity as 
trademarks. Manual of Patent Examining Procedure §608.01 (v) states (emphasis 
added): 

Although the use of trademarks having definite meanings is permissible in 
patent applications, the proprietary nature of the marks should be 
respected. Trademarks should be identified by capitalizing each letter 
of the mark (in the case of word or letter marks) or otherwise indicating 
the description of the mark (in the case of marks in the form of a symbol 
or device or other nontextual form). Every effort should be made to 
prevent their use in any manner which might adversely affect their validity 
as trademarks. 

Applicants respectfully suggest that "Java" is accompanied in each instance 
throughout the application with a registered trademark symbol "®" to "otherwise indicate 
the description of the mark" of Sun Microsystems, Inc., that the Manual of Patent 
Examining Procedure is written in permissive language not mandatory language, i.e., 
"[trademarks should" rather than trademarks "shall", and that inclusion of the symbol 
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"®" is as respectful to the mark as capitalization. Thus, Applicants believe that use of 
"Java®" throughout the application is respectful of the trademark. 

Further, Applicants believe that the meaning associated with "Java®" is 
sufficiently communicated in the specification and that addition of "the generic 
terminology" is unnecessary. Manual of Patent Examining Procedure §608.01 (v) states: 

Names used in trade are permissible in patent applications if: 

(A) Their meanings are established by an accompanying definition which 
is sufficiently precise and definite to be made a part of a claim, or 

(B) In this country, their meanings are well known and satisfactorily 
defined in the literature. 

The meaning of "Java®" is widely used and well known in the industry, at least in 

the United States, and defined thoroughly in literature. In addition, the specification 

describes the invention in general terms and provides specific examples of how the 

invention may be embodied via "Java®" implementations. In particular, the specification 

defines classes and methods and then provides examples of classes and methods that 

may be used in embodiments of the invention as "Java® classes" and "Java® 

methods". The following examples illustrate their use: 

This would not be a problem for purely procedural subroutines, but when 
the subroutines have static storage of one form or another (including the 
static data structures associated with C++ or Java® classes) then 
errors will result unless a single static storage image is somehow shared 
between all copies. (Specification, Background, pg. 3, lines 11-15; 
emphasis added). 

The present invention functions by dividing categories (or subcategories of 
the categories) of static items storage into two super-categories: Those 
categories that are unique to an individual compiled instance of a 
subroutine, and those categories that are shareable between individual 
compiled instances, provided that they all reflect the same source version. 
Note that there may be some items that may be placed into either super- 
category, as they are not malleable (and hence don't need to be shares) 
but also do not contain information unique to the particular compiled 
instance of a subroutine. Such things as the name of the Java® class 
would fall into this group. (Specification, Detailed Description of the 
Preferred Embodiment, pg. 10, lines 27-30 and pg. 11, lines 1-4; 
emphasis added). 
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When a compiler determines that a subroutine ( .g., a Java® method or 
oth r procedure) should be copied into a compilation unit where it was 
not already defined, a "clone" copy of the permanent data structures for 
the containing class is also made. (Specification, Detailed Description of 
the Preferred Embodiment, pg. 11, lines 11-13; emphasis added). 

Since "Java®" is well defined, respectfully used, and used in a manner to further 
describe general descriptions of the invention by example, Applicants respectfully 
request that the objections related to "Java®" be withdrawn. 

Claims 1-28 are pending in the application. Claims 1-28 remain pending 
following entry of this response. 

Claims 7, 16, 22, 25, 26, and 28 stand rejected under 35 U.S.C. § 112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which Applicants regard as the invention because the term "Java®" is 
mutable and indefinite. More specifically, the Examiner's rejection states that "[u]se of 
the trademarked term makes the claims dependent on a technology which only has 
meaning as defined by Sun Microsystems" and is directed toward claims that include 
the phrases: "Java® classes", "Java® method" and "Java® methods". Applicants 
respectfully traverse the rejection. 

As discussed above, the meaning of "Java®" is well known in the industry and 
thoroughly defined in literature and, after general descriptions of classes and methods 
for use with embodiments of the invention, the specification describes specific examples 
of the classes and methods that conform to the general definitions including "Java® 
classes" and "Java® methods" (see the quotes above). Since the phrases "Java® 
classes" and "Java® methods" conform to the general definitions of classes and 
methods described in the specification and, in addition, are subject to the meaning of 
"Java®" that is well known in the industry and thoroughly defined in literature, the 
meanings of the phrases "Java® classes" and "Java® methods" are definite and well 
defined. Possible future changes in the meaning of "Java®" alluded to by the Examiner, 
whether by Sun Microsystems, Inc. or by other sources, that would significantly 
contradict descriptions of classes and methods described in the specification, may then 
fall outside the scope of the meanings of the phrases "Java® classes" and "Java® 
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methods" as defined by the specification, but only to the extent that future changes in 
the meaning of "Java®" are contradictory. Accordingly, Applicant respectfully requests 
that the rejections of claims 7, 16, 22, 25, 26, and 28 be withdrawn and the claims be 
allowed. 

Claims 1-21, 23, and 24 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Evans et al. (US 5,805,899; hereinafter Evans). Applicants respectfully 
traverse the rejection. 

A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single reference. Verdegaal Bros. v. 
Union Oil Co. of California, 814 F.2d 628, 631, 2 U.S.P.Q.2d 1051, 1053 (Fed. Cir. 
1987). Furthermore, the identical invention must be shown in as complete detail as is 
contained in the claim. Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236, 9 
U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989). 

With regard to independent claims 1, 10, and 17, the Examiner's rejection states: 

As per claims 1, 10, and 17, Evans teaches, "copying each of said 
external resolution items into said one compilation unit to form respective 
internal resolution items" (Evans, col. 2, II. 8-11); 

The specification describes an embodiment of "copying each of said external 

resolution items into said one compilation unit to form respective internal resolution 

items" on page 12 at lines 23-25 (emphasis added): 

At step 1925, a copy of the called external subroutine or other 
addressable item, along with a version indicium of the external 
subroutine or other addressable item is copied into the compilation 
unit 

Evans (in col. 2, II. 8-11), however, does not copy "external resolution items into 

said one compilation unit to form respective internal resolution items." Evans, simply 

copies a version definition and a version symbol into a versioned object. Evans, in col. 

2 at lines 8-17 states (emphasis added): 

... At build time, a link-editor adds data to a versioned object defining 
all available versions of the object (a version definition section and a 
version symbol section). At build time the link-editor adds data to the 
software application defining the version requirements of the software 
application S (a version dependency section). At runtime, a runtime 
linker verifies that th requirements of th software application 
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match the version definition stored in the obj cts themselves, #. 
that the v rsioned object need d by th software application is 
available to the runtime linker. 

Evans copies data to verify the version of an object and verifies the object is 
correct at runtime rather than copying the "external resolution items into said one 
compilation unit." Since Evans does not anticipate this limitation, Evans does not 
anticipate claims 1,10, and 17. Thus, Applicants respectfully request that the rejection 
of claims 1,10, and 17 be withdrawn and those claims be allowed. 

Further, since the independent claims 1,10, and 17 include limitations that are 
not anticipated by Evans, the claims dependent upon claims 1,10, and 17 (dependent 
claims 2-7, 11-16, and 18-21) also include limitations that are not anticipated by Evans 
and are also in condition for allowance. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 
(Fed. Cir. 1988). Accordingly, Applicants request that the rejections with respect to 
dependent claims 2-7, 11-16, and 18-21 also be withdrawn and the claims be allowed. 

With regard to independent claim 8, the Examiner's rejection states: 

As per claim 8, Evans discloses, "comparing ... cloned and external 
entities" (Evans, Fig. 2b, item 114). 

The Examiner suggests that claim 8 is anticipated but provides no supporting 
evidence from Evans that another limitation of claim 8, the element "executing said 
cloned called entity in the case of said version identifiers comparing favorably," is 
anticipated by Evans. Since each and every element of claim 8 must be anticipated by 
Evans, the Office Action does not provide a prima facie case that claim 8 is anticipated 
by Evans. Thus, Applicants respectfully request that the rejection be withdrawn and 
claim 8 be allowed. 

Further, since a prima facie case has not been established for independent claim 
8, a prima facie case has not been established to support a rejection of the claim 
dependent upon claim 8 (dependent claim 9), so claim 9 is also in condition for 
allowance. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). Accordingly, 
Applicants request that the rejection with respect to dependent claim 9 also be 
withdrawn and the claim be allowed. 
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Claims 22-28 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Evans and Nally et a/., (US 6,298,478; hereinafter Nally). Applicant respectfully 
traverses the rejection. 

To establish a prima facie case of obviousness, three basic criteria must be met. 
Manual of Patent Examining Procedure §2142. First, there must be a suggestion or 
motivation to modify or combine the references. In re Vaeck, 947 F.2d 488, 493, 20 
USPQ2d 1438, 1442 (Fed. Cir. 1991). Second, there must be a reasonable expectation 
of success in the modification or combination. In re Merck & Co., Inc., 800 F.2d 1091, 
1097, 231 USPQ 375, 379 (Fed. Cir. 1986). Finally, the modification or combination 
must teach or suggest all of Applicants' claim limitations. In re Royka, 490 F.2d 981, 
985, 180 USPQ 580, 583 (CCPA 1974). 

With regard to claim 22, the Examiner's rejection states that Evans does not 
disclose "resolving Java® methods ... outside said common compilation in the event of 
a version conflict" but Nally (col. 18, II. 24-33) does disclose the use of "Java® methods" 
in an internal and external role if the versioning conflicts. 

Neither Nally nor Evans teach or suggest all the limitations of claim 22. In 

particular, claim 22 describes a framework for not just "resolving Java® methods" but 

"resolving Java® methods" as "cloned versions of Java® methods within a compilation 

unit." Claim 22 states (emphasis added): 

A framework for loading class data structures prior to execution and for 
resolving called Java® methods, said framework preferentially 
resolving said called Java® methods as cloned versions of Java® 
methods within a compilation unit common to a calling Java® method, 
said framework resolving respective called Java® methods outside said 
common compilation unit in the event of a version conflict between said 
respective cloned and external Java® methods. 

As discussed above, Evans copies version definitions and version symbols. 
However, Evans does not teach or suggest "cloned versions of Java® methods within a 
compilation unit." 

Nally, in col. 18 at lines 24-33, describes a process of locating a version of an 
entity bean by going up the processing chain to find the correct version of the entity 
bean (emphasis added): 
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When it is determined that an application or application user attempts to 
access an EJB for update (i.e. to write to the EJB) (Block 800), the EJB 
Object for the EJB being accessed seeks the current version in the view 
for the currently-active transaction (Block 805). If a v rsion ofth ntity 
bean for this EJB is not found for the current transaction (Block 810), 
the processing goes up the transaction chain, checking the view for 
each transaction to see if a version of the entity bean can be found in 
the transaction chain (Block 815). 

The quotations of Evans and Nally, although discussing an ability to detect and 
handle different versions of code, do not teach or suggest "cloned versions of Java® 
methods within a compilation unit." As such, the combination of Evans and Nally do not 
suggest or teach all the limitations of claim 22. Therefore, Applicants respectfully that 
the rejection be withdrawn and claim 22 be allowed. 

Further, as all the limitations of independent claim 22 have not been taught or 
suggested by the combination of Evans and Nally, the claims dependent upon claim 22 
(dependent claims 23-28) incorporate by reference limitations that are not taught or 
suggested by the combination of Evans and Nally and are also in condition for 
allowance. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). Accordingly, 
Applicants request that the rejections with respect to dependent claims 23-28 be 
withdrawn and the claims be allowed. 
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In conclusion, the references cited by the Examiner, neither alone nor in 
combination, teach, show, or suggest the claims of the present invention. Having 
addressed all issues set out in the Office Action, Applicants respectfully submit that the 
claims are in condition for allowance and respectfully request that the claims be 
allowed. 

Respectfully submitted, 

GeroG. Median 
Registration No. 44,227 
Moser, Patterson & Sheridan, LLP. 
3040 Post Oak Blvd., Suite 1500 
Houston, TX 77056 
Telephone: (713)623-4844 
Facsimile: (713)623-4846 
Attorney for Applicant(s) 
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